A transaction is one or more operations on a physical and abstract application state that must all complete, or if they do not all complete, then must all be reversed (i.e., rolled back). For example, a transaction may involve moving money from one bank account to another, by debiting a first account, and crediting a second account. In this example, the entire transfer operation must complete, or if there is a failure after the debit but before the credit, then the debit is rolled back. A fundamental feature of an application server, such as the WebLogic Server product, is transaction management. Transactions are a means to ensure that database transactions are completed accurately and that they take on all “ACID” properties of a high-performance transaction, including:
Atomicity—all changes that a transaction makes to a database are made permanent; otherwise, all changes are rolled back.
Consistency—a successful transaction transforms a database from a previous valid state to a new valid state.
Isolation—changes that a transaction makes to a database are not visible to other operations until the transaction completes its work.
Durability—changes that a transaction makes to a database survive future system or media failures.
WebLogic Server, a product of BEA Systems, Inc. of San Jose, Calif., is an example of application server software that supports both distributed transactions and a two-phase commit protocol for enterprise applications. A distributed transaction is a transaction that updates multiple resource managers (such as databases) in a coordinated manner. Resource managers can be on different computers or domains. In contrast, a local transaction updates a single resource manager.
A domain is a unit of administration and processing grouping several application servers that may be running on the same or different computers. In one embodiment, a domain is a logically related group of resources. In one embodiment, domains include a special server instance called the Administration Server, which is the central point from which an administrator configures and manages all resources in the domain.
In the context of this document an insecure connection is a network connection between two application servers running on the same domain or in different domains that is lacking network transport security mechanisms such as the Secure Sockets Layer (SSL) or Transport Layer Security (TLS).
The two-phase commit protocol is a method of coordinating a single transaction across two or more resource managers. It guarantees data integrity by ensuring that transactional updates are committed in all of the participating resource managers, or are fully rolled back out of all the resource managers, reverting to the state prior to the start of the transaction. In other words, either all the participating resources are updated, or none of them are updated.
Distributed transactions typically involve the following participants:
Transaction originator—initiates the transaction. The transaction originator can be, e.g., a user application, an Enterprise JavaBean (EJB), or a Java Messaging Server (JMS) client.
Transaction manager—manages transactions on behalf of application programs. A transaction manager coordinates commands from application programs to start and complete transactions by communicating with all resource managers that are participating in those transactions. When resource managers fail during transactions, transaction managers help resource managers decide whether to commit or roll back pending transactions. Transaction managers are also known as transaction subsystems.
Recoverable resource—provides persistent storage for data. The resource is most often a database.
Resource manager—provides access to a collection of information and processes.
Transaction aware Java Database Connectivity (JDBC) drivers are common resource managers. Resource managers provide transaction capabilities and permanence of actions; they are entities accessed and controlled within a distributed transaction. A set of operations made on behalf of a transaction on a particular resource manager is called a transaction branch.
The first phase of the two-phase commit protocol is called the prepare phase, or simply phase 1. The required updates are recorded in a transaction log file, and the resource must indicate, through a resource manager, that it is ready to make the changes. Resources can either vote to commit the updates or to roll back to the previous state. The second phase of the two-phase commit protocol is called the commit phase, or simply phase 2. What happens in the second phase (i.e., the commit phase) depends on how the resources vote. If all resources vote to commit, all the resources participating in the transaction are updated. If one or more of the resources vote to roll back, then all the resources participating in the transaction are rolled back to their previous state.
Transactions are appropriate in the example situations described below (although these situations are merely illustrative and not exhaustive).
As a first example, the client application needs to make invocations on several objects, which may involve write operations to one or more databases. If any one invocation is unsuccessful, any state that is written (either in memory or, more typically, to a database) must be rolled back. For example, consider a travel agent application. The client application needs to arrange for a journey to a distant location; for example, from Strasbourg, France, to Alice Springs, Australia. Such a journey would inevitably require multiple individual flight reservations. The client application works by reserving each individual segment of the journey in sequential order; for example, Strasbourg to Paris, Paris to New York, N.Y. to Los Angeles. However, if any individual flight reservation cannot be made, the client application needs a way to cancel all the flight reservations made up to that point. The client application needs a conversation with an object managed by the server application, and the client application needs to make multiple invocations on a specific object instance. The conversation may be characterized by one or more of the following:
data is cached in memory or written to a database during or after each successive invocation;
data is written to a database at the end of the conversation;
the client application needs the object to maintain an in-memory context between each invocation;
each successive invocation uses the data that is being maintained in memory across the conversation;
if during the conversation there is a failure, the client application needs the ability to cancel all database write operations that may have occurred during or at the end of the conversation.
As an alternate example, consider an Internet-based online shopping cart application. Users of the client application browse through an online catalog and make multiple purchase selections. When the users are done choosing all the items they want to buy, they proceed to check out and enter their credit card information to make the purchase. If the credit card check fails, the shopping application needs a mechanism to cancel all the pending purchase selections in the shopping cart, or roll back any purchase transactions made during the conversation. Within the scope of a single client invocation on an object, the object performs multiple edits to data in a database. If one of the edits fails, the object needs a mechanism to roll back all the edits. In this situation, the individual database edits are not necessarily using Enterprise Java Beans (EJBs) or Remote Method Invocations (RMIs). A client, such as an applet, can obtain a reference to the Transaction and TransactionManager objects, using Java Naming and Directory Interface (JNDI), and start a transaction.
As another example, consider a banking application (mentioned above). The client invokes the transfer operation on a teller object. The transfer operation requires the teller object to make the following invocations on the bank database: invoking the debit method on one account; and invoking the credit method on another account. If the credit invocation on the bank database fails, the banking application needs a mechanism to roll back the previous debit invocation.
Application servers that support distributed transactions, such as the WebLogic Server, are typically unable to process secure transactions coordination calls over insecure connections.
A possible solution to processing transaction coordination calls over insecure connections is the use of transport security—Secure Sockets Layer (SSL) or Transport Layer Security (TLS) mutual authentication. However, this solution is not always viable.
A problem with issuing transaction coordination calls over insecure connections is that an attacker can use a man-in-the-middle attack to obtain information about a transaction coordinator and sub-coordinators, and use this information to maliciously alter the termination of a transaction. Accordingly, there is still a need for a solution that would protect transaction coordination messages against man-in-the-middle attacks. Preferably, such a solution would require minimal administrative setup and have a minimal impact on performance.